I think this should be part of new option to enable / disable optimizations. Another opportunity for optimizations is coalescing common properties:

/* for example: */
.foo { width: 10px; height: 10px; color: red; }
.bar { width: 10px; height: 10px; color: yellow; }
/* would become: */
.foo, .bar { width:10px; height:10px; }
.foo { color: red; }
.bar { color: yellow }

This kind of optimization is not safe however and therefore users should be able to test and see what side effects if any appear.

+1

This may not be 100% related to this thread but I've seen every other marginally related ticket being closed and referred here.

Specifically for dealing with media queries it would be useful to use some sort of output buffering to stash some css rules for later inclusion. The issue is hinted at in the media queries blog article where trying to correct for media queries inline will result in a number of identical @media declarations that have different rules in them. Output buffering will solve this really well. Each buffer would be named and additive so each time it is invoked, more is appended to the end of it. Once a buffer is output it is flushed.

Buffering is a completely different usecase than a @mixin. Buffers would allow for the creation of a responsive grid plugin that expected specific buffers for specific @media blocks. Additionally it'd be useful for projects that want to create print styles using @print blocks. Currently the only way to manage this is to simply add your additional rules directly to the media queries which is effective but can make the code a little harder to track. Not having buffers also completely removes the capability of using canned media queries baked into a compass extension, making it harder to convert projects like 320 and up into SASS for easy re-use.

Here's a simple example:

.left-column {
  width: 300px; // for browsers that don't support media queries
  @buffer small-devices {
    & { width: 100%; }
  }
  @buffer medium-devices {
    & { width: 150px; }
  }
  @buffer large-devices {
    & { width: 300px; }
  }
}
.main-column {
  width: 660px; // for browsers that don't support media queries
  @buffer small-devices {
    & { width: 100%; }
  }
  @buffer medium-devices {
    & { width: 330px; }
  }
  @buffer large-devices {
    & { width: 660px; }
  }
}


@media only screen and (min-width: 0) {
  @output small-devices;
}
@media only screen and (min-width: 768px) {
  @output medium-devices;
}
@media only screen and (min-width: 992px) {
  @output large-devices;
}

• buffers are output at the time that @output is called in the natural CSS order. So if you add to a buffer after it's been output, nothing happens.
• you can easily add more to a buffer using the names.
• it might be useful to clear a named buffer with something like @clean my-buffer;
• I don't know if it's possible to use the & symbol in content blocks like in my example but it'd be really useful.
• It would also be useful to use the bubbling feature similar to how @media works. Something like div { @buffer my-buffer { width: 100px; } width: 200px; }

Didn't think about an output buffer approach for media queries but I gotta say it doesn't look bad.

+1

The buffer solution really looks good here...

+1

yeah +1 for the buffer !

+1

• 1 and + 1 for media query squishing!

+1 for everything suggested!

+1 for sure.

+1 Great solution. Buffer would be a great feature.

+1 for not repeating "@media screen and" a thousand times in my live file

I've been hacking on a @buffer support in Sass and progress can be seen on StanAngeloff/sass@nex3:master...StanAngeloff:feature/buffers The code is working at the moment, but lacks some features (see further down).

I plan on using this for my own projects, but if there is enough interest and the code is bug-free, I would be happy to submit a pull request for inclusion in core Sass.

The syntax I used is:

$device-size:  small;
$device-width: 640px;

body {
  color: white;
  @buffer #{$device-size}-screen {
    color: black;
  }
}

h1 {
  color: white;
  @buffer #{$device-size}-screen {
    color: black;

    .no-js & { color: red; }
  }
}

@media only screen and (max-width: #{$device-width}) {
  @flush #{$device-size}-screen;
}

Several features can be seen in action in the snippet above:

• Rule bubbling
• Interpolations
• Parent selector (&) support
• Converting between .scss <=> .sass using sass-convert

There is support for using @buffer within .sass files as well:

$device-size:  small
$device-width: 640px

body
  color: white
  #{$device-size}-screen ->
    color: black

h1
  color: white
  #{$device-size}-screen ->
    color: black

    .no-js &
      color: red

@media only screen and (max-width: #{$device-width})
  <- #{$device-size}-screen

What doesn't work / is missing

• Error reporting and debugging has not been tested extensively
• Buffer functions are not provided, e.g., buffer-exists(..) or buffer-empty(..)
• This one is more for personal use -- ability to write buffers to files, i.e., generating media-specific files so main stylesheet can remain optimised for desktop screens

Try it out

• Clone the repo

  $ git clone git://github.com/StanAngeloff/sass.git

• Check out the feature/buffers branch

  $ cd sass
  $ git checkout feature/buffers

• Build and install the gem

  $ gem build *.gemspec
  $ gem install --local *.gem

Feedback welcomed very much.

@StanAngeloff Very interested by this, it would be great if this was implemented into Sass.

+1

Does anyone have any reasoning for why this wouldn't be possible?

+1. Media queries are fundamentals these days, so would be really handy a more efficient way to manage the output to group them. Could be the one suggested by @heygrady —great idea BTW—, or another one, but would be nice to see some changes in the current approach.

+1

@StanAngeloff Please open a separate pull request for your @buffer stuff so we can discuss it further. It's not directly related to this feature request.

@nex3 I think that @heygrady should open the separated pull request, since was his original idea and he probably can explain more in deep the matter. It's a really good idea the @buffer stuff. BTW: great work with the hacking @StanAngeloff.

+1. Would love to see something like this.

@imbatta I didn't write any code, I was just offering an idea. I couldn't create a pull request without code. But thanks for thinking of me.

@heygrady Oh, you're right, I kinda suck in some GitHub stuff yet; sorry for the misunderstood. Hope the @buffer thing end up implemented.

But coming back to the original feature request, I don't think it's a good idea. These kind of compilation will cause many headaches for sure. Anyway, if many people is interested, it could be an optional way to compile.

+1

I like @lunelson's idea of applying @buffer to mixins: #116 (comment).

It should group mixin @flush dumps by matching mixin arguments. For example:

@mixin breakpoint($width) {
    @media (min-width: $width) {
        @content;
    }
}
@buffer breakpoint(700px) {
    h1 {
        color: red;
    }
}
@buffer breakpoint(700px) {
    p {
        color: blue;
    }
}
@buffer breakpoint(900px) {
    p {
        color: purple;
    }
}
@flush breakpoint;

Should output:

@media (min-width: 700px) {
    h1 {
        color: red;
    }
    p {
        color: blue;
    }
}
@media (min-width: 900px) {
    p {
        color: purple;
    }
}

+1 for @append

@append is a much cleaner, and more broadly applicable solution to the problem @buffer tries to solve.

(LESS has additive mixin declarations, which can be a real pain, but also proves incredibly powerful at times.)

+1

+1 to use the css-condense logic.

👍

Late to the party, but to me, an extension to Sass based on @stoyan's CSSShrink would be fantastic for intelligent compression. I do understand the challenges there though. Not trivial at all. http://cssshrink.com/velocity/

+1 for buffer

For anyone who is using gulp, just use https://www.npmjs.com/package/gulp-combine-media-queries

It will combine your media queries together for you after compilation is complete. Works perfectly.

+1 for buffer

+1 for buffer. Being able to nest related CSS and then control where it gets output seems like a generally useful tool. Something like:

@buffer("label") {
  // SCSS code
}

@flush("label");

Then...

// Mobile First BABY!!
.box {
  margin: 20px 10px;

  @buffer("tablet") {
    margin-left: 20px;
    margin-right: 20px;
  }

  @buffer("desktop") {
    margin-top: 40px;
    margin-bottom: 40px;
  }
}

// elsewhere

@media (min-width: 600px) {
  @flush("tablet"); // Outputs .box overrides and anything else in "tablet" buffer
}

@media (min-width: 900px) {
  @flush("desktop"); // Outputs .box overrides and anything else in "desktop" buffer
}

+1 for buffer

Hi!

I saw this discussion is really old, but I think there's something new to be considered: HTTP/2.

Soon, the good practice concerning requests will be "it depends". On HTTP/2 is better to split the CSS by media query and to reduce the file size. So, maybe it's better to keep every @media on its own file and to import or not on a screen widt basis; or we could @flush content buffered on another file... I don't know. I'm new to SASS. What I know is that the situation is changing from when this discussion began.

Thanks!

+1

+1

hi,
I wrote an article about the targeting of styles in Sass
http://www.matov.pro/blog/adaptivity-targeting-styles
it is realy now

+1

Please use emoji, instead of +1. Use comments for something really helpful for the issue.

Ok, sorry for that.

El 7/6/16 a las 12:10, Dmitry Polushkin escribió:

Please use emoji, instead of +1.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#116 (comment), or
mute the thread
https://github.com/notifications/unsubscribe/ABPv4mkrDCIZf3Tni8KwSE3hvHq0tLe9ks5qJUOjgaJpZM4AAU9t.

David Saenz / david@herokidstudio.es mailto:david@herokidstudio.es /
www.herokidstudio.es http://www.herokidstudio.es / 93 320 90 90 ·
Pamplona 89, 3 · 08018 Barcelona

_Herokid Studio_™

Use postcss.

https://github.com/hail2u/node-css-mqpacker
https://github.com/ben-eb/postcss-merge-rules

These optimizations are no longer planned. Sass does what it can to eliminate extra whitespace and choose the smallest possible representation for values, but it's primary focus is being the best preprocessing language it can be rather than the best CSS compressor. Other tools exist that are focused on maximal optimization, and those are a better place for features like this.

In addition:

• Combining namespaced selectors requires a lot of knowledge about the semantics of specific CSS property names, which is against Sass's design policy. Baking that knowledge into the language increases the amount of effort we as maintainers have to put in to keeping on top of the latest CSS specifications, and makes Sass more brittle to future CSS changes.

• Ignoring overridden declarations is not generally safe. It's possible to use overridden declarations intentionally to provide fallback styles for browsers that don't support recent features. As above, we don't want to have to keep Sass up-to-date with which properties may or may not be safe to eliminate.